Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

.github/workflows/release-benchmarks.yml (1)

20-22: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Duplicated/fragile uv_version resolution — see consolidated comment.
Deferring detailed analysis to the consolidated comment covering this file plus semgrep-sarif.yml and benchmarks.yml.

Also applies to: 41-50

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release-benchmarks.yml around lines 20 - 22, Consolidate
the uv_version resolution used by this workflow with the shared resolution used
in semgrep-sarif.yml and benchmarks.yml. Update the relevant setup and
references so uv_version is determined once through the canonical mechanism,
rather than being independently or fragilely resolved in each workflow; leave
the CARGO_TERM_COLOR and RUST_BACKTRACE settings unchanged.

.github/workflows/semgrep-sarif.yml (1)

25-25: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Duplicated/fragile uv_version resolution — see consolidated comment.
Deferring detailed analysis to the consolidated comment covering this file plus benchmarks.yml and release-benchmarks.yml.

Also applies to: 37-46

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/semgrep-sarif.yml at line 25, Consolidate the duplicated
uv_version resolution in this workflow with the equivalent logic in
benchmarks.yml and release-benchmarks.yml. Define or reuse one authoritative
resolution mechanism and update all affected references, including the
additional block noted by the comment, while preserving the existing
version-selection behavior.

.github/workflows/benchmarks.yml (1)

49-49: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Duplicated/fragile uv_version resolution — see consolidated comment.
Deferring detailed analysis to the consolidated comment covering this file plus semgrep-sarif.yml and release-benchmarks.yml.

Also applies to: 70-79

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/benchmarks.yml at line 49, The uv_version resolution is
duplicated and fragile across the benchmark workflows. Consolidate it into one
reliable shared definition and update the benchmark configuration around
BENCHMARK_TIMEOUT to reuse that value consistently, including the corresponding
resolution in semgrep-sarif.yml and release-benchmarks.yml.

.github/workflows/generate-baseline.yml (1)

57-61: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Guard justfile version resolution against empty results. All three workflows resolve pinned tool versions with grep '^var :=' justfile | cut -d '"' -f 2 but never assert the result is non-empty. If a justfile variable is renamed or removed, resolution silently produces an empty string — most dangerously in generate-baseline.yml, where an empty version: input to setup-uv can fall back to installing the latest release and quietly break the intended pin. The cargo-install consumers fail, but with an opaque error rather than a clear "version not found in justfile" message.

• .github/workflows/generate-baseline.yml#L57-L61: after computing version, add set -euo pipefail and [ -n "$version" ] || { echo "::error::uv_version not found in justfile" >&2; exit 1; } before writing GITHUB_OUTPUT.
• .github/workflows/rust-clippy.yml#L39-L45: validate both CLIPPY_SARIF and SARIF_FMT resolved to non-empty values before appending to GITHUB_OUTPUT.
• .github/workflows/audit.yml#L48-L53: validate version is non-empty before writing GITHUB_OUTPUT.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/generate-baseline.yml around lines 57 - 61, Guard all
pinned-tool version resolution against empty values: in
.github/workflows/generate-baseline.yml lines 57-61, enable strict shell
handling and validate uv_version before writing GITHUB_OUTPUT, emitting the
specified error and exiting when absent; in .github/workflows/rust-clippy.yml
lines 39-45, validate both CLIPPY_SARIF and SARIF_FMT before output; in
.github/workflows/audit.yml lines 48-53, validate version before output.

.github/workflows/ci.yml (1)

64-89: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Extract the just-version bootstrap into a shared composite action. All three workflows duplicate the identical "grep justfile for just_version → install just → just --evaluate the rest" sequence, with no error handling if the grep/cut fails to find a version (an empty version would silently install just@ with no pin).

• .github/workflows/ci.yml#L64-L89: replace this block with a call to a shared composite action (e.g. .github/actions/resolve-just) that outputs just's resolved version and installs it, then keep only the file-specific just --evaluate list.
• .github/workflows/codecov.yml#L37-L67: same replacement; keep only cargo_llvm_cov_version/nextest_version evaluation.
• .github/workflows/papers.yml#L69-L97: same replacement; keep only tectonic_version/tex_fmt_version/uv_version evaluation.

Also consider failing fast if version resolves empty (e.g. [ -n "$version" ] || { echo "::error::could not resolve just_version from justfile"; exit 1; }) in the shared action.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ci.yml around lines 64 - 89, Extract the duplicated
just-version resolution and installation into a shared composite action, such as
.github/actions/resolve-just, exposing the resolved just version and installing
it for callers. Add validation there to fail with an error if just_version
cannot be resolved from justfile. In .github/workflows/ci.yml lines 64-89,
retain only the workflow-specific tool evaluations; apply the same replacement
in .github/workflows/codecov.yml lines 37-67 while retaining
cargo_llvm_cov_version and nextest_version, and in .github/workflows/papers.yml
lines 69-97 while retaining tectonic_version, tex_fmt_version, and uv_version.

.github/actions/resolve-uv/action.yml (2)

12-24: 📐 Maintainability & Code Quality | 🔵 Trivial

Duplicated version-resolution logic with resolve-just.

This shell block (grep + cut + empty check) is nearly identical to the one in .github/actions/resolve-just/action.yml (Lines 12-24). Consider extracting a single parameterized composite action (e.g. accepting the justfile variable name as an input) to avoid maintaining two copies of the same parsing logic.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/actions/resolve-uv/action.yml around lines 12 - 24, Extract the
duplicated version-resolution shell logic from the resolve step and the
corresponding resolve-just action into one parameterized composite action. Make
the action accept the justfile variable name as an input, reuse the shared
grep/cut/empty-check behavior, and update both callers to supply their
respective variables while preserving the existing output and error behavior.

---

18-22: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Make uv version parsing more robust The current grep '^uv_version :=' ... | cut -d '"' -f 2 path is brittle: a spacing or quoting change in justfile would make resolution fail and exit via the empty check. Consider a more defensive parse or a structured source for the version.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/actions/resolve-uv/action.yml around lines 18 - 22, Update the uv
version resolution in the action’s version-parsing block to tolerate spacing and
quoting variations in the justfile declaration, while still extracting the
intended uv_version value. Preserve the existing empty-value validation and
error behavior, and avoid relying on the fixed quote delimiter and exact spacing
used by the current grep/cut pipeline.

src/delaunay/builder.rs (1)

2167-2172: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Add regression coverage for the relaxed explicit-construction path.

Please verify tests for both a valid non-Delaunay explicit mesh and a realization-invalid mesh, including supported dimensions where feasible. This branch changes both the proof returned by the builder and the propagated error variant.

As per coding guidelines, tests should verify mathematical, geometric, and topological invariants and cover dimensions 2 through 5 whenever feasible.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/delaunay/builder.rs` around lines 2167 - 2172, Add regression tests
covering the relaxed explicit-construction branch around
validate_realization_only and into_realization_validated_delaunay: verify a
valid non-Delaunay mesh succeeds with the expected realization proof, and a
realization-invalid mesh propagates
ExplicitConstructionError::RealizationValidation. Cover supported dimensions 2
through 5 where feasible, asserting relevant mathematical, geometric, and
topological invariants.

Source: Coding guidelines

.github/workflows/rust-clippy.yml (1)

39-61: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Consider just --evaluate instead of grep/cut for resolving tool versions.

Parsing justfile with grep '^clippy_sarif_version :=' is brittle: it breaks silently on reformatting (indentation, quote style, inline comments). just --evaluate <variable> resolves the variable using just's own parser and is robust to formatting changes.

♻️ Proposed fix using `just --evaluate`

-          clippy_sarif="$(grep '^clippy_sarif_version :=' justfile | cut -d '"' -f 2 || true)"
+          clippy_sarif="$(just --evaluate clippy_sarif_version || true)"
           if [[ -z "$clippy_sarif" ]]; then
             echo "::error::Could not resolve clippy_sarif_version from justfile"
             exit 1
           fi

-          sarif_fmt="$(grep '^sarif_fmt_version :=' justfile | cut -d '"' -f 2 || true)"
+          sarif_fmt="$(just --evaluate sarif_fmt_version || true)"

This assumes just is already installed/available on the runner before this step (e.g. via a prior setup-just step) — please confirm that's the case for this job.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/rust-clippy.yml around lines 39 - 61, Update the “Resolve
Clippy SARIF tool versions” step to obtain clippy_sarif_version and
sarif_fmt_version through just --evaluate rather than grep/cut parsing of
justfile. Preserve the existing empty-value validation, error messages, and
GITHUB_OUTPUT assignments, and confirm the job has just installed or available
before this step.

docs/RELEASING.md (1)

76-104: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Consider reminding maintainers to sync the CITATION.cff abstract with README.md.

The citation-review checklist covers author/ORCID/repository/license/DOI but doesn't mention keeping the abstract field mirrored with README.md's Introduction paragraph.

As per coding guidelines, "Keep the first paragraph under README.md's Introduction mirrored in the abstract field of CITATION.cff; update both together."

📝 Proposed addition

 Review the citation identity fields at the same time: author, ORCID,
 repository, license, and DOI. Keep the DOI policy deliberate: update it only
 when the release has a known release-specific DOI or the archival policy
 changes.
+
+If README.md's Introduction paragraph changed since the last release, update
+`CITATION.cff`'s `abstract` field to match it.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/RELEASING.md` around lines 76 - 104, Update the release metadata
checklist in docs/RELEASING.md to explicitly require keeping CITATION.cff’s
abstract synchronized with the first paragraph under README.md’s Introduction,
updating both together alongside the existing citation identity review.

Source: Coding guidelines

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

tests/triangulation_builder.rs (1)

811-874: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Consider documenting the geometric intent of the fixture generators.

shared_facet_vertices/shared_facet_simplices and crossing_cone_vertices/crossing_cone_simplices encode fairly intricate, dimension-generic coordinate/simplex constructions (shared-facet apex placement, cone-axis extension) with no comments explaining what scenario each is meant to exercise. A short doc comment per function (what geometric configuration it produces and why) would help future maintainers verify/extend these fixtures without reverse-engineering the arithmetic.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/triangulation_builder.rs` around lines 811 - 874, Add concise Rust doc
comments to shared_facet_vertices, shared_facet_simplices,
crossing_cone_vertices, and crossing_cone_simplices describing the geometric
configuration each fixture constructs and the triangulation scenario it
exercises, including the shared-facet apex placement and cone-axis extension.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

docs/validation.md (1)

31-37: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Table column doesn't match its own header after the rename.

The "Depends on realization?" column expects Yes/No, but the Level 1 row now reads "Local coordinates only" (line 33) — inconsistent with rows 2–5. Additionally, the Level 4 row still says "Geometric realization" (line 36) while the rest of the doc renamed this concern to "Valid Realization" (line 28, line 529 heading). Worth reconciling both for consistency.

📝 Suggested fix

-| 1 | Local object correctness | Local coordinates only |
+| 1 | Local object correctness | No |
 | 2 | Combinatorial structure | No |
 | 3 | Intrinsic PL topology | No |
-| 4 | Geometric realization | Yes |
+| 4 | Valid realization | Yes |
 | 5 | Geometric predicates | Yes |

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/validation.md` around lines 31 - 37, Update the validation table to keep
the “Depends on realization?” column values consistent with its Yes/No header,
changing the Level 1 entry to the appropriate value. Also rename the Level 4
concern from “Geometric realization” to “Valid Realization” to match the
terminology used elsewhere in the document.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes